\chapter{Bilan}
\section{Les besoins initiaux}
Ce projet avait donc pour but de réaliser un système permettant l'envoi de contenu sur un Raspberry-Pi, afin de le diffuser sur la télévision ou les enceintes auxquelles il est branché.

\section{Tests et retours utilisateurs}
Par manque de temps, nous n'avons pas été en mesure de mener une procédure
complète de tests. Cependant, nous avons testé une partie de l'application
Airpi, en procédant à des tests JUnit sur la UserList. Nous avons aussi fait passer des tests de robustesse aux différentes applications pour les fonctionnalités implémentées telles que le rafraîchissement des listes d'utilisateurs et de médias, ou encore l'envoi des requêtes par l'application au serveur dedié aux smartphones.

\section{Comparaison entre le planning prévisionnel et le planning réel}
Nous avions établi un planning prévisionnel au début de ce projet. Celui-ci
avait pour but de déterminer les grandes étapes du projet, leur ordres
d’exécution ainsi qu’une approximation de leur durée. La première phase du
projet correspond à la modélisation et au développement de l’application du
Raspberry-Pi ainsi qu'aux pages web du serveur Tomcat. Nous avons passé beaucoup
plus de temps sur la partie débogage, au détriment de la partie test. Enfin dans
la seconde partie du projet, celle qui concerne l’intégration des applications
\emph{smartphone}, nous avons perdu un peu de temps. Cela peut s’expliquer par
le fait que nous appréhendions de nouvelles technologies (développement iOS,
développement Android). De plus, la mise en place d’un système de \og{} vrai
\emph{streaming}\fg{} a nécessité des ressources ainsi que du temps. Les difficultés rencontrées au cours de cette phase nous on fait prendre du retard sur la rédaction et la réalisation des documents de synthèse, tels que le rapport, ou encore la sountenance orale. A noter également que cette seconde phase à permis l’amélioration de l’application du Raspberry-Pi aussi bien dans la gestion des pages web que pour les applications \emph{smartphone}.

\section{Evolution future du projet}
Ce projet est destiné à devenir \emph{open source}. Ainsi, nous comptons mettre en ligne le code source de notre application. De cette manière, chacun pourra apporter ses modifications et améliorations, corrections de bogues, ou tout simplement récupérer une partie du code afin de s'en servir dans son propre projet. Nous souhaiterions aussi développer une API permettant de faciliter la gestion de OMXPlayer dans un logiciel.

\section{Ce que nous avons appris}
Ce projet nous a permis d'acquérir de nombreuses connaissances, tant sur le plan technique qu'organisationnel. En effet, nous avons eu l'occasion de nous initier à de nombreuses technologies, telles que le Java Entreprise Edition pour l'application du Raspberry-Pi, l'Objective C pour l'application iOS, le XML pour l'application Android, le HTML, CSS, AJAX et JSON pour les pages web, et quelques commandes shell pour contrôler OMXPlayer. De plus, nous nous sommes rendus compte de la nécessité de bien préparer et organiser le travail en amont, afin de ne pas être obligés de faire des modifications dans le code qui auraient pu être évitées si tous les cas avaient été anticipés. Nous avons donc constaté à quelle point la phase de modélisation est primordiale.

\section{Critiques}
Malgré le fait que notre projet réponde à l'intégralité du cahier des charges, quelques points sur la façon de développer et sur le produit final sont criticables.

\bigskip

On peut notamment remettre en question le choix du langage retenu pour la programmation de l'application du Raspberry-Pi. En effet, le Java EE n'était pas forcément le langage le plus adapté pour ce genre de cas de figure. Il aurait été plus pertinent de choisir un langage tel que Python par exemple, qui est plus \og léger\fg{}. Ce langage n'a pas besoin d'embarquer une machine virtuelle comme le fait le Java, ce qui économise des ressources. La programmation dans ce langage aurait sûrement été plus facile, surtout qu'un très grand nombre de bibliothèques sont disponibles. Cependant, nous souhaitions nous essayer à la technologie Java EE, car nous possédons une bonne maîtrise de Java, et c'est un langage qui nous intéresse. 

\bigskip

Lors du développement des différentes applications, nous nous sommes aperçus que lors de la phase de conception, nous n'avions pas assez modélisé. Cela nous a posé problème car nous avons manqué de repères, et nous avons donc perdu du temps à recréer des modèles.

\bigskip

D'un point de vue plus général, nous nous sommes rendus compte que notre projet peut poser des problèmes de droits d'auteur. En effet, les musiques que les utilisateurs peuvent envoyer sur le Raspberry-Pi sont susceptibles de ne pas leur appartenir. Cela n'est pas de notre responsabilité, car une fois lue, la musique est immédiatement supprimée : il n'y a donc pas de stockage. Le cas est le même pour le téléchargement de liens vidéos. Nous citons beaucoup la plateforme de vidéos Youtube, car elle est la plus connue. Cependant, télécharger les vidéos qui y sont présentes n'est pas autorisé. Mais une fois de plus, nous ne sommes pas responsables des actions des utilisateurs.

